Patrick Elliott <sel### [at] rraznet> wrote:
> If you have something like:

> #declare yy = clock
> sphere {...
>   translate <yy,35,61>
>   texture { some_complex_texture translate 100*x}
>   translate y*2}

> Then you **must** reparse the object every single time, because once the 
> object exists internally, it can't be changed.

  Wrong.

  The object has its own transformation matrix and the texture its own.
All transformations applied to the object go to its transformation matrix,
and all transformations applied to the texture (be it directly in the
texture block or indirectly in the object block) go to the transformation
matrix of the texture.
  It would be perfectly possible to alter these two transformation matrices
afterwards. It's simply a question of which transformations are applied to
the object only, which ones to the texture only and which ones to both.

> The 
> transforms you need to be able to change are "not" sitting conveniently 
> as the last thing in the object, they are buried deep within the 
> structure.

  You seem to have this concept that the transformations are somehow
stored in the definition of the object, and that this order must be
preserved.

  The individual transformations are not stored anywhere. Each transformation
is simply a command (a kind of "function call" if you like) which modifies
the internal transformation matrix of the object.

  It would be perfectly possible, after the object has been created (with
the transformations and all), to reset its transformation matrix and then
apply the same transformations to it, resulting in the exact same end
result. The only distinction you have to make is which transformations
go to the object, which ones to the texture and which ones to both.

> If we want to be able to animate, without a reparse, we need 
> an internal representation that allows "each" transform, texture, 
> object, etc. to exist as accessible elements, not as static 
> declarations.

  No we don't.

> In other words, you need to make it "look" like:

> yy = yy + 1
> mysphere.translate(0)=yy,35,61

> Even as the engine keeps track of "how" those things connect:

> start->translate(0)->texture(0)->translate(1)->end

  The engine doesn't need to keep track of that. You should acquaint
yourself with transformation matrices and how they work.

> How else do you both allow animation, without a reparse, but also 
> maintain the capacity to place as many transforms, or other elements, 
> into the object as you can now?

  You can write a thousands individual transformations into an object,
yet none of them will be (individually) stored anywhere. They are all
applied to one single 4x4 transformation matrix. POV-Ray doesn't need
to keep track of the individual transformations nor store them anywhere.

  The only thing you need to specify is whether a certain transformation
is applied to the object, to the texture, or both.

> See what I am getting at? If you want to maintain the "existing" SDL, 
> you have to allow for this, or suffer the current consequence of having 
> to reparse the "entire" SDL every frame.

  That's just not true. The only thing you have to allow in the new SDL
is to be able to apply transformations to the object only, the texture
only or both at the same time. This is very trivial to do.
  It's perfectly possible to transform the object but not the texture
even after the texture has been specified.

-- 
                                                          - Warp

Post a reply to this message